這週的分享來跟大家聊聊一些軟體建設的基礎，因為常常在和朋友聊天的時候，談到一些公司導入敏捷開發，但執行起來卻不是很順暢的情境，所以想趁這個機會和大家聊聊我的一些想法。
使用敏捷方法進行開發最大的好處是能夠盡快的交付價值，並且收集反餽，作為快速疊代的基礎。但往往敏捷失敗最大的原因，是忽略了先建立好能夠支持敏捷方法的基礎建設，舉例來說，如果今天沒有足夠的單元測試、自動化測試，那怎麼可能保證在快速交付的同時，維持產品的品質呢？
舉一個很實際的例子，假設今天我們是一個 ”成熟” 的敏捷開發團隊，每一個 Sprint (兩週) 固定可以完成 20 個 User story，而目前團隊已經完成 100 個 User story 功能上線，我們每一個 Sprint 的目標是，在盡可能交付新的 User story 的同時，要確保原本既有的功能使用正常，這樣才能夠對客戶帶來最良好的使用者體驗。這樣的情境假設應該是每一個敏捷團隊希望達成的目標，甚至是希望能夠透過持續改進的方式，讓團隊和產品成長的同時，交付速度越來越快，但是由於團隊希望可以專注在 「交付價值」（注意這邊這個交付價值的定義），所以一切都以 ”開發” 功能為優先，在 Merge PR 或是上線前再多做一些測試確保功能正常。這一切聽起來都非常的合理，大家專注在交付價值，但是在幾個 Sprint 之後，卻發現使用者抱怨系統問題的頻率變高了？
這個情境其實是一個很常見的誤區，由於想要趕快先交付價值，讓系統上線，所以打算等有空的時候再補測試，或是先用手動測試，但卻忽略了功能成長時測試案例增加的速度，如果原本團隊已經有 100 User story，每週可以穩定交付 20 個新的 User story，那麼只要 5 個 Sprint，需要驗證的功能數量就會變成一開始的 2 倍，只要經過一年，測試的工作量就會將近變成 7 倍，通常到最後都會變成，只測試覺得有被修改的部分，或是感覺需要測試的部分，剩下大部分的功能都不會被測試到，自然而然產品就會越來越多小問題，也越來越不敢隨意修改，反而導致開發速度大幅度下降，甚至是因為不敢大幅度的修改，失去了重構的機會，然而讓程式碼更難維護，然後又發生越來越多的問題，進入了一個惡性的循環！
所以從一開始定義正確價值交付就是一個很重要的議題，在定義產出的時候，就必須要把維持產品品質最低限度的標準都包含進去，例如是否有經過 Linter 確保程式碼風格一致，所有產出的 Feature 都包含單元測試、自動化測試甚至是安全測試或壓力測試等等，讓這些成為產出的標準，自然而然就可以在持續疊代的同時，維持產品的品質，甚至是持續優化交付的速度！所以當進行敏捷開發時，必須要時時刻刻的檢視自己是否有把「品質」當作一個重要的指標，能夠很好的了解自己的產品價值所在，注重軟體開發的本質，才能夠更進一步的有穩定的疊代產出！
基本功是無論如何還是很重要的啊，如果沒有好好的打好基礎，不管用的方法工具再先進，都是跑不快的！
Search